One type of software is referred to as a “runtime”. A runtime provides underlying functionality that can be used by multiple applications that run on a computing system. One distinct type of runtime is called a “continuation based runtime”. A continuation based runtime executes activities. An activity represents a unit of executable code that consists of multiple pulses of work. For instance, suppose an activity is to receive messages. In that case, one pulse of work might be to set up the computing system with proper configuration and state to receive messages, and then pause until a message is received. Another pulse of work might occur when a message is received, which might involve setting up the message so that data can be extracted from the message. Another pulse of work might be to extract the data from the message itself, and so forth. In between pulses the runtime may generate a continuation, allowing for an appropriate pause.
One of the ways an activity can execute multiple pulses of work is through the scheduling of child activities. This composition of activities enables custom control flows that can be implemented through the scheduling of child activities 0, 1 or n times as determined by the composite activity. Beyond this flexibility to create new control flows, activities in a continuation based runtime have a number of distinct characteristics. For instance, such activities have no process affinity in that they can be paused in one process, and resumed in a different process, and may also run on different threads. Such activities can also be persisted into persistent storage for later rehydration back into memory.
Continuation based runtimes are capable of initiating and managing transactions. However, continuation based runtimes are much more difficult, if not impossible, to be incorporated in transactions that are generated outside of the continuation based runtime, at least not without the guarantees of atomicity, consistency, isolation, and durability expected for a transaction.